Network Working Group D. Katz 
Request for Comments: 1103 Merit/NSFNET 
June 1989 


A Proposed Standard for the Transmission of 
IP Datagrams over FDDI Networks 


Status of this Memo 


This RFC specifies a method of encapsulating the Internet Protocol 
(IP) [1] datagrams and Address Resolution Protocol (ARP) [2] requests 
and replies on Fiber Distributed Data Interface (FDDI) Networks. 

This RFC specifies a proposed protocol standard for the Internet 
community. Comments are welcome. Distribution of this memo is 
unlimited. 
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Conventions 


The following language conventions are used in the items of 
specification in this document: 


"Must" or "Mandatory"--the item is an absolute requirement of the 
specification. 


"Should" or "Recommended"--the item should generally be followed 
for all but exceptional circumstances. 


"May" or “Optional"--the item is truly optional and may be 
followed or ignored according to the needs of the implementor. 


Introduction 


The goal of this specification is to allow compatible and 
interoperable implementations for transmitting IP datagrams and ARP 
requests and replies. 


The Fiber Distributed Data Interface (FDDI) specifications define a 
family of standards for Local Area Networks (LANs) that provides the 
Physical Layer and Media Access Control Sublayer of the Data Link 
Layer as defined by the ISO Open System Interconnection Reference 
Model (ISO/OSI). Documents are in various stages of progression 
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toward International Standardization for Media Access Control (MAC) 
[4], Physical Layer Protocol (PHY) [5], Physical Layer Medium 


Dependent (PMD) [6], and Station Management (SMT) [7]. The family of 
FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9, 
TOTA 


The remainder of the Data Link Service is provided by the IEEE 802.2 
Logical Link Control (LLC) service [11]. The resulting stack of 
services appears as follows: 


+------------- + 
| IP/ARP | 
+------------- + 
| 802.2 LLC | 
+------------- + 
| FDDI Mac | 
+------------- + 
| FDDI PHY | 
+------------- + 
| FDDI PMD | 
+------------- + 


This memo describes the use of IP and ARP in this environment. At 
this time, it is not necessary that the use of IP and ARP be 
consistent between FDDI and IEEE 802 networks, but it is the intent 
of this memo not to preclude Data Link Layer interoperability at such 
time as the standards define it. 


Packet Format 


IP datagrams and ARP requests and replies sent on FDDI networks must 
be encapsulated within the 802.2 LLC and Sub-Network Access Protocol 
(SNAP) data link layers and the FDDI MAC and physical layers. The 
SNAP must be used with an Organization Code indicating that the SNAP 
header contains the EtherType code (as listed in Assigned Numbers 
[12]). 


802.2 LLC Type 1 communication (which must be implemented by all 
conforming 802.2 stations) is used exclusively. All frames must be 
transmitted in standard 802.2 LLC Type 1 Unnumbered Information 
format, with the DSAP and the SSAP fields of the 802.2 header set to 
the assigned global SAP value for SNAP [11]. The 24-bit Organization 
Code in the SNAP must be zero, and the remaining 16 bits are the 
EtherType from Assigned Numbers [12] (IP = 2048, ARP = 2054). 
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.-------- +-------—- +-------- + 
MAC Header FDDI MAC 
-------- +--------+--------+ 
+-------—- +-------—- +-------—- + 
DSAP=K1| SSAP=K1| Control 802.2 LLC 
+-------—- +-------—- +-------- + 
+-------- +-------- +--------- +-------- +-------- + 
Protocol Id or Org Code =K2| EtherType | 802.2 SNAP 
+-------- +-------- +--------- +-------—- +-------- + 


The total length of the LLC Header and the SNAP header is 8 
octets. 


The K1 value is 170 (decimal). 
The K2 value is 0 (zero). 
The control value is 3 (Unnumbered Information). 
Address Resolution 
The mapping of 32-bit Internet addresses to 16-bit or 48-bit FDDI 
addresses must be done via the dynamic discovery procedure of the 


Address Resolution Protocol (ARP) [2]. 


Internet addresses are assigned arbitrarily on Internet networks. 
Each host’s implementation must know its own Internet address and 


respond to Address Resolution requests appropriately. It must also 
use ARP to translate Internet addresses to FDDI addresses when 
needed. 


The ARP protocol has several fields that parameterize its use in any 


specific context [2]. These fields are: 
hrd 16 - bits The Hardware Type Code 
pro 16 - bits The Protocol Type Code 
hin 8 - bits Octets in each hardware address 
pin 8 - bits Octets in each protocol address 
op 16 - bits Operation Code 


The hardware type code assigned for IEEE 802 networks is 6 [12]. 
FDDI networks, although not IEEE 802 networks per se, are 
semantically equivalent and use the same type code. 


The protocol type code for IP is 2048 [12]. 
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The hardware address length is 2 for 16-bit FDDI addresses, or 6 for 
48-bit FDDI addresses. 


The protocol address length (for IP) is 4. 
The operation code is 1 for request and 2 for reply. 
Broadcast Address 


The broadcast Internet address (the address on that network with a 
host part of all binary ones) must be mapped to the broadcast FDDI 
address (of all binary ones) (see [13]). 


Trailer Formats 


Some versions of Unix 4.x bsd use a different encapsulation method in 
order to get better network performance with the VAX virtual memory 
architecture. Consenting systems on the same FDDI network may use 
this format between themselves. Details of the trailer encapsulation 
method may be found in [14]. However, all hosts must be able to 
communicate using the standard (non-trailer) method. 


Byte Order 


As described in Appendix B of the Internet Protocol specification 
[1], the IP datagram is transmitted over FDDI networks as a series of 
8-bit bytes. This byte transmission order has been called "big- 
endian" [15]. 


MAC Layer Details 
Packet Size 
The FDDI MAC specification [4] defines a maximum frame size of 
9000 symbols (4500 octets) for all frame fields, including four 


symbols (two octets) of preamble. This gives the following MAC 
layer overhead: 
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Field Size in Octets 


Preamble 2 
Start Delimiter 1 
Frame Control 1 
Destination Address 6 (2) 
Source Address 6 
FCS 4 
End Delimiter/Frame Status 2 


Total 22- (14) 
Remaining for Data 4478 (4486) 


Subtracting the 8 byte LLC/SNAP header, this gives a maximum 
packet size (MTU) of 4470 (4478) octets. For compatibility 
purposes, the maximum packet size used with IP datagrams or ARP 
requests and replies must be consistent on a particular network. 


The overhead calculations (above) assume a standard Frame Status 
field consisting of three symbols. Additional Implementor Defined 
frame status information, although permitted by the FDDI MAC 
specification, must not be used with IP datagrams because it 
affects the maximum packet size. 


Gateway implementations must be prepared to accept full-length 
packets and fragment them when necessary. 


Host implementations should be prepared to accept full-length 
packets; however, hosts must not send datagrams longer than 576 
octets unless they have explicit knowledge that the destination is 
prepared to accept them. A host may communicate its size 
preference in TCP-based applications via the TCP Maximum Segment 
Size option [16]. 


Datagrams on FDDI networks may be longer than the general Internet 
default maximum packet size of 576 octets. Hosts connected to an 
FDDI network should keep this in mind when sending datagrams to 
hosts that are not on the same local network. It may be 
appropriate to send smaller datagrams to avoid unnecessary 
fragmentation at intermediate gateways. Please see [16] for 
further information. 


There is no minimum packet size restriction on FDDI networks. 
Other MAC Layer Issues 


The FDDI MAC specification does not require that 16-bit and 48-bit 
address stations be able to interwork fully. It does, however, 
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require that 16-bit stations have full 48-bit functionality, and that 
both types of stations be able to receive frames sent to either size 
broadcast address. For use with IP and ARP, all communicating 
stations on a LAN must use a consistent address size. 

Implementations must discard any IP or ARP packets received with an 
unimplemented or inactive address size. 16-bit and 48-bit 
implementations may coexist on the same FDDI network; however, if 
they wish to interwork they must be considered separate IP networks 
and linked with an IP router capable of supporting 16-and 48-bit 
addresses simultaneously. 


Group (multicast) addresses are defined by the FDDI MAC specification 
but are not necessarily supported by existing hardware. Therefore, 
this feature must not be used by IP and ARP. 


The FDDI MAC specification defines two classes of frames, 
Asynchronous and Synchronous. Asynchronous frames are further 
controlled by a priority mechanism and two classes of token, 
Restricted and Unrestricted. Only the use of Unrestricted tokens and 
Asynchronous frames are required by the standard for FDDI 
interoperability. The priority mechanism is currently implemented 
locally by the transmitting station and the Priority field in 
Asynchronous frames is ignored by other stations. This field will 
likely be interpreted by Transparent Bridges once they are defined. 
There is no default value for priority called out in the MAC 
standard. 


Therefore, all IP and ARP frames must be transmitted as Asynchronous 
frames using Unrestricted tokens, and the Priority value is a matter 
of local convention. Implementations should make the priority a 
tunable parameter for future use. It is recommended that 
implementations provide for the reception of IP and ARP packets in 
Synchronous frames. 


After packet transmission, FDDI provides Frame Copied (C) and Address 
Recognized (A) indicators. There are four possible combinations of 
the indicators with the following semantics: 


(C) (A) 

Reset Reset The frame was not received by any station. 
Reset Set The addressed station is congested. 

Set Reset Reserved. 

Set Set The addressed station received the frame. 


Implementations may use these indicators to provide some amount of 
error detection and correction: 


If the Frame Copied bit is reset but the Address Recognized bit is 
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set, receiver congestion has occurred. It is recommended, though 
not mandatory, that hosts retransmit the offending packet a small 
number of times (4) or until congestion no longer occurs. 


If the both the Address Recognized indicator and the Frame Copied 
indicator are reset, an implementation has three options: (1) 
ignore the error and throw the packet away, (2) return an ICMP 
destination unreachable message to the source, or (3) delete the 
ARP entry which was used to send this packet and send a new ARP 
request to the destination address. The latter option is the 
preferred approach since it will allow graceful recovery from 
first hop bridge and router failures and changed hardware 
addresses. 


As of this writing there is a proposal within ANSI to set the 
Frame Copied indicator and reset the Address Recognized indicator 
when a frame is forwarded by a Transparent Bridge. For future 
compatibility, implementations should interpret this combination 
of indicators as if the frame were successfully delivered to the 
destination (i.e., do nothing). 


IEEE 802.2 Details 


While not necessary for supporting IP and ARP, all implementations 
must support IEEE 802.2 standard Class I service in order to be 
compliant with 802.2. This requires supporting Unnumbered 
Information (UI) Commands, eXchange IDentification (XID) Commands and 
Responses, and TEST link (TEST) Commands and Responses. 


When an XID or TEST command is received, a response must be returned 
with Destination and Source addresses, and DSAP and SSAP, swapped. 


When responding to an XID or a TEST command, the value of the Final 
bit in the response must be copied from the value of the Poll bit in 
the command. 


The XID command or response has an LLC control field value of 175 
(decimal) if the Poll/Final bit is off or 191 (decimal) if the 
Poll/Final bit is on. 


The TEST command or response has an LLC control field value of 227 
(decimal) if the Poll/Final bit is off or 243 (decimal) if the 
Poll/Final bit is on. 


Command frames are identified by having the high order bit of the 
SSAP address reset to zero. Response frames have the high order bit 
of the SSAP address set to one. 
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XID response frames must include an 802.2 XID Information field of 
129.1.0 indicating Class I (connectionless) service. 


TEST response frames must echo the information field received in the 
corresponding TEST command frame. 


Appendix on Numbers 


The IEEE specifies numbers in bit transmission order, or bit-wise 
little-endian order. The Internet protocols are documented in byte- 
wise big-endian order. This may cause some confusion about the 
proper values to use for numbers. Here are the conversions for some 
numbers of interest. 


Number IEEE IEEE Internet Internet 
HEX Binary Binary Decimal 

UI Op Code co 11000000 00000011 3 

SAP for SNAP 55 01010101 10101010 170 

XID F5 11110101 10101111 175 

XID FD 11111101 10111111 191 

TEST C7 11000111 11100011 227 

TEST CF 11001111 11110011 243 

Info 818000 129.1.0 
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